Many deployed systems run various different software applications. At times, some of those applications require, for example, software modifications, upgrades, updates and/or security patches downloads. When such software modifications, upgrades, updates and/or security patch downloads are made, the system may need to be rebooted in order to effectuate the changes in the applications. For example, in cable or satellite systems, a system operator at a head-end may be required to remotely modify code that may reside on set-top boxes which may be located in, for example, subscribers' homes. These types of software modifications, upgrades, updates and/or security patch downloads should be done in a secure manner, since it may be important to ensure that there is no compromise in system integrity. Hence, for example, hackers should not be able to take control of a set-top box or other devices when software modifications, upgrades, updates and/or security patch downloads are being made.
For security purposes, such applications would typically require a boot loader code or boot code, which would relate specifically to the application and would be used to help facilitate any such changes and/or modifications. To meet the requirement for ‘divorce,’ that is, changes in the applications in deployed systems, the application-specific boot code cannot be the primary boot loader. This is because the primary boot loader code must be able to load independently in order to be able to download a new application boot code. Furthermore, the primary boot code is owned by the deployed system owner rather than the application. For these reasons, a dual boot architecture is required, where the system primary boot code would run, and then it can select and load a security specific boot code, a secondary boot code, which would in turn load and run the application code related to the secondary boot code.
To protect against the potential security threats during boot situations, the standard method for boot protection is to use a boot memory, typically a ROM, which causes a signature check of the boot code each reset cycle. However, this boot ROM today would only cause a check of the primary boot loader. Extending security protection to subsequent phases in system boot, for example, when the secondary boot code and application are loaded and run, is clearly desirable. This is currently achieved using a software chain of trust from the ‘ROM checked’ primary boot code. This primary boot loader software signature checks a secondary boot loader and then jumps to it. This secondary boot loader signature checks the main application and jumps to it.
One problem associated with such a process is that the only hardware-based check takes place during the primary boot code verification. In the subsequent phases of system boot, the system becomes vulnerable to possible security breaches, especially when the execution is from flash memory, a relatively simple, slow and therefore vulnerable bus. Enhancing protection during boot operations would improve the system protection against potential security breaches.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.